1. Statement of the Technical Field
The present invention relates to the field of software installation and more particularly to software un-installation.
2. Description of the Related Art
The installation of software has long proven to be challenging even to the most sophisticated of end users. Prior to the advent of the multiprocessing and multitasking operating system, software installation in the personal computing context often merely required the transfer of program files from portable media such as a floppy diskette to fixed storage. On occasion, where the program to be installed exceeded in size that which could be hosted in a single floppy diskette, the installation process could span the multiple diskettes ultimately resulting in the assembly of all required program files in a strategic location on disk.
When graphical windowing operating systems stormed the marketplace in the early 1990s, no longer did the copying of program files suffice in the installation of a computer program. Rather, complex configuration of the application, the windowing operating system, or both could be required depending upon the level of integration required for the effective, trouble-free operation of the application in within the graphical environment. Initially, the complex configuration could be specified in a separate text file such as an initialization file. Subsequently, as the windowing environment itself transformed into an ultra-complex system, registry entries would become the de facto medium for persisting configuration elements of an application. In both cases, however, sophisticated installation programs became the norm in deploying new software applications.
Significantly, given the complexity of the modern software installation process, a great many number of opportunities exist for the installation to fail. Accounting for this possibility, many conventional software installation applications permit a counter-installation process known in the art as an un-installation process. In the prototypical un-installation process, all files transferred to fixed storage can be removed, e.g. deleted, and all entries applied to the registry can be purged from the registry. The un-installation process can become complicated, however, where registry entries are not added, but changed, and where all files added may already support the operation of other installed applications. Of course, it is to be recognized by the skilled artisan that registry entries in of themselves are limited to files and application settings and do not relate the deployment of application objects or components. Moreover, registry entries mostly relate to a single computing platform and cannot be scaled to the enterprise.
In any case, oftentimes shared files cannot be removed during an un-installation process lest their removal affect the operation of other already installed applications. Similarly, those registry entries which have been modified merely cannot be removed lest their removal similarly affect the operation of an application dependant upon the existence the registry entry. Rather, to place the system in a state which existed prior to the installation of the application, the registry entries must be “rolled-back” and only those files which had been added to the system and which are not relied upon by other applications in the system must be removed.
Presently, rollback technologies exist typically as part of installation processes and as part of the underlying operating system. For instance, in one popular office productivity suite, every file and registry removed by the installation process can be saved to a hidden folder. When the installation process has completed successfully, the hidden folder and all of its contents can be deleted. When the installation process is cancelled or fails before the process can complete, the installation process can refer the hidden folder to rollback the registry to its former state and to replace any files which had been removed up to the point of failure.
Despite the advancement of installation technologies, rollback methodologies alone do not completely address the matter of a failed software installation. Specifically, though an application can be completely installed without incident, the subsequent operation of the installed application either can fail to effectively coexist with other installed applications, or can fail in its own operation. In either case, it would be preferable to completely remove the newly installed application as if the installed application had never been. Unfortunately, conventional rollback technologies cannot accommodate the foregoing circumstance because rollback technologies remain effectively only during the course of the installation process.
Personal computing systems recently have been distributed with blanket rollback technologies in which the entire image of the system can be replaced with a previous image which existed before the occurrence of a failed installation. Nevertheless, the blanket rollback approach can be described as heavy handed in as much as it is not desirable to rollback the state of the system so that desirable state changes in the system are rolled back along with the effect of the failed installation. Moreover, the blanket rollback technology requires a manual determination that an installation has failed.
Yet, in the computing environment of the twenty-first century, determining that an installation failure has occurred often is a matter of subjective determination which is not easily resolved through the manual intervention of a human being. Accordingly, it would be desirable to implement the effect of rollback technologies in a manner so as to permit the rolling back of a failed installation when it can be determined that an application installation has failed though the installation process itself may have completed successfully. Moreover, it would be desirable to extend the effect of rollback technologies to the deployment of application objects and components, both within a single computing platform and in a scaled manner in the computing enterprise.